Units of duration in QTP7

Question

Units of duration in QTP7

I am using AppleScript to play audio through QTP7, employing the following key lines:

tell application "QuickTime Player 7" to play document 1

repeat

display dialog "Interrupt" buttons {"Stop", "Pause"} giving up after my secLeft()

--etc

endrepeat

on secLeft()

tell application "QuickTime Player 7"

tell document 1

set d to (duration - current time)

end tell

--set d to round d * 0.00166 rounding down -- library pop music

--setdtoroundd * 0.00002268 roundingdown -- library classical music

return d

end secLeft

Display dialog disappears after a number of seconds set by secLeft().

One would suppose, that duration and current time are given in seconds too, but that is not the case, so I have to correct d to express it in seconds.

I have two iTunes libraries with each a different correction factor; within a library the correction factor is the same for each song, at least I hope so, and until now that seems to be the case.

Until recently duration and current time were expressed in seconds in QTP, but after updating to Mountain Lion I ran into problems; the switch to QTP7 could also be the culprit.

My questions:

1. Why are duration and current time not simply expressed in seconds?

2. More importantly, what determines the correction factor and what can I expect for my next iTunes library?

Maybe I should address these questions to the designers of AppleScript of QTP7, but where?

iMac, OS X Mountain Lion (10.8.2), FileMaker Pro 11

Posted on Jan 22, 2013 7:29 AM

Reply

Answer 1

Pierre L.

Level 5

4,641 points

Jan 22, 2013 4:52 PM in response to A.P.M. Wülfinghoff

I don't know much about QuickTime Player and can't actually answer your questions. Nevertheless, maybe the following script can give you some interesting information:

tell application "QuickTime Player 7"

tell document 1 -- Chiquitita, from ABBA Gold: Greatest Hits

{duration, time scale, duration / time scale, duration / time scale / 60}

end tell

--> {14318592, 44100, 324.68462585034, 5.411410430839}

The last result (5.41 min = 5 min 25 s) is the same as the song duration (5:25) that can be found in the info window of the .m4a audio file.

Moreover, 1 ÷ 44100 = 0,00002268, which is actually your second correction factor.

Are you bold enough to read this?

Message was edited by: Pierre L.

Reply

Answer 2

Camelot

Level 9

59,451 points

Jan 22, 2013 9:14 PM in response to A.P.M. Wülfinghoff

According to the dictionary, duration should be in seconds, but dictionaries have been known to be wrong.

Indeed, the simple tests I've run here do indicate that to be the case. However, Pierre's post offers a clue:

Moreover, 1 ÷ 44100 = 0,00002268, which is actually your second correction factor.

44,100 as a frequency equates to 44.1KHz, which is a common audio frequency encoding. Therefore I'm guessing that your issue lies somewhat with the specific type of files you're using and the fact that the duration needs to be divided by the frequency to obtain the clock time duration. If that's the case then the issue does, indeed, lie on a per-file basis since each file could be encoded at a different rate. You can probably check the 'data rate' property of the file to find its encoding rate and use that to calculate the duration.

Reply

Answer 3

Jan 23, 2013 11:53 AM in response to Camelot

My answer to both of you, Pierre L. and Camelot.

I am always amazed at the depth of your knowledge.

I know just enough of AppleScript to realize what cannot be done in FMP.

Let me first tell you what I found out before I read your answers.

Apparently because of Mountain Lion AppleScript no longer reads the duration of iTunes, expressed in milliseconds, but the underlying duration in the music file, which is translated by iTunes into milliseconds.

It took me a day to figure out, that the difference lies in the type of music file, mp3 or m4a (also AAC).

My classical music library is fairly recent and all music was imported as m4a files; the popular music library is older and consists of 90% mp3 and 10% m4a files.

I ran Chiquita and the data were different, because my Chiquita is a mp3 file.

In fact, the mp3 time scale of 600 corresponds to my factor 0,00166, the m4a time scale to my factor 0.00002268, as uou both indicated.

So I will use the time scale to determine what type the audio file is - I hadn't yet figured that out - and then apply the corresponding correction factor bij dividing by 600 or 44100.

Thanks for your inspiration, and yes I shall be bold enough to study the article.

Reply